前言
本篇將了解漏洞管理當中，除了漏洞管理之外，還可以利用 SSDLC 的方法，利用治本的方式直接寫出安全的程式碼內容。
為什麼會有漏洞產生
基本上都是使用的系統，在撰寫程式碼的過程當中，沒有寫出安全的程式碼或是佈署的時候發生問題，導致有漏洞。
- 人為撰寫錯誤：開發者可能缺乏安全意識，因此在撰寫程式碼的時候，使用
- 具有漏洞的函式庫：可能無法修復、不知道問題點在哪裡
- 歷史共業：寫程式的時候可能是接手過去其他工程師開發的內容，不清楚也不了解過去的架構，導致新的程式碼內容可能有安全性的問題。
- 技術更新：可能有新的攻擊手法出來
- 時間與資源的壓力：很多企業為了要開發新的產品，以及搶占市場先機，因此沒有顧及安全性的問題，因此安全的問題會擺在後面，甚至沒有。
開發流程從哪裡來
主要可以查看 Microsoft 提出的內容，以下稍微整理以下來自 About Microsoft SDL的內容
-
21 世紀初的背景：
- 家用個人電腦日益普及。
- 網路使用廣泛。
- 惡意軟體的增加，且試圖攻擊家用個人電腦。
-
2002年：
- 微軟推出「可信任的計算」的內容。
- 目標：使產品和服務有高度安全、可用、可靠並具有業務誠信。
-
微軟 SDL 的誕生：
-
2004年：
- SDL 成為微軟軟體開發過程的核心部分。
- 同時也代表資安工作的策略性投資。
-
SDL 的演進：
- 軟體設計、開發和測試的方式發生了改變。
- 已發展為一個明確的方法論。
-
現狀：
- SDL 仍是微軟開發產品和服務的基石。
- 隨新技術如行動設備、雲端計算、物聯網、人工智慧等的興起，SDL 持續演進。
SSDLC（Secure Software Development Lifecycle）
是一種安全的開發流程，旨在軟體開發生命周期的各個階段中，以安全為主導進行設計、開發、測試和部署。
開發工程師，如果透過 SSDLC，可以在自己開發的軟體、網站加入安全性的考量，也有助於降低被攻擊的風險。
主要流程
SSDLC 的主要流程如下：
- 規劃與培訓
- 需求階段
- 設計階段
- 撰寫程式碼階段
- 測試階段
- 部署階段
可能的問題
標準流程很美好，但事實上許多時候導入會是一個硬需求，
對於導入SSDLC，可能會遇到的問題和挑戰包括：
-
企業文化與抗拒
導入新的流程往往需要改變企業的現有文化和工作方式。員工可能會抵抗改變，尤其是當員工認為這會增加工作負擔。
-
資源分配
SSDLC 需要額外的時間和人力來確保每一步都考慮到安全性。在緊急的專案時程和有限的資源下，會被視為挑戰。
-
缺乏專業知識
不是所有的開發者和專案經理都熟悉安全的開發流程。可能需要進一步的培訓和專業的資安團隊的 Support。
-
工具和技術
選擇和整合合適的工具是一個挑戰，特別是在考慮到成本和兼容性的情況底下。
-
維護問題
即使成功地導入了SSDLC，也需要定期更新和維護以確保其持續有效性，如果沒有更新可能也會有資安問題。
-
管理層支持
在沒有管理階層的強烈支持和承諾的情況下，導入 SSDLC 可能會遭遇困難。
可能會覺得你浪費時間。
-
對快速完成的壓力
在現今的敏捷和 DevOps 文化中，快速交付與完成是一個關鍵要素。
因此，可能存在壓力，使得安全性成為次要考慮。
-
過度依賴自動工具
雖然自動化工具在安全測試中是很有價值的，但過度依賴它們可能會忽略某些人為的測試和審查過程，這些過程可能會捕捉到工具錯過的問題。
因此，如果真的需要導入 SSDLC，企業需要有充分的準備和計劃，並確保得到了所有關鍵管理層的支持。
培訓階段
- 多個部門都要一起參與
- 基礎目的是希望先了解 SSDLC 在做什麼
- 先從安全意識培養開始
- 再針對軟體開發流程與開發培訓
漏洞的影響性
可以利用案例來了解一個漏洞可能會有哪一些的影響，讓開發者意識到這些問題，並且讓開發者有意識的在撰寫的過程當中，真的知道應該怎麼寫比較安全。
Web 與 API 開發
針對網站常見的漏洞開始了解，可以參考 OWASP TOP 10 以及 OWASP API TOP 10 ，可以嘗試整理出：
- 漏洞的原理是什麼？
- 駭客怎麼利用這些漏洞的？
- 如何避免這些漏洞？
- 之後開發過程當中是否可以自己檢查內容？
APP 開發安全
- 確認是哪一個平台：Android 與 iOS
- 常見的 APP 漏洞
- 可以參考 APP 檢測的流程
- 可以從以下的方面著手
- 資料怎麼儲存
- 資料怎麼傳輸
- 資料怎麼被使用
- 權限有多大
不管是 APP 、 Web 、 API 都需要注意邏輯漏洞的問題。
而 APP 也要注意如果被逆向應該要注意哪一些問題：
- 帳號密碼不該寫死在程式碼當中
- 設定檔與敏感的變數都應該要加解密
- 不能使用太弱的密碼演算法
常見設定問題
- 是否有最小化權限
- 是否有禁止使用 Administrator 與 root 的使用
- 禁止跳板機登入敏感伺服器
- 禁止共享帳號與密碼
- 是否有制定機房進出的規範
- 是否有懲罰或獎勵條款
需求階段
確認軟體開發需求，"通常" PM 會告訴你需求，然後開發，但有時候隕石開發該怎麼辦？
◇ 在這裡跟大家建議，先確認整體 "資料流向" 再確認目前這些資料 "誰可以瀏覽、新增、刪除、修改"，可以優先確認整體的 "權限" 問題。
為什麼這樣建議
我們在攻擊過程當中，無法被自動化弱點掃描找到的漏洞是 "程式邏輯" 相關的漏洞，最難防禦、影響最大的也是 "程式邏輯" 漏洞。
漏洞名稱包含 IDOR(權限控管相關的漏洞)、還有商業邏輯漏洞。
還需要確認什麼
你撰寫的程式，是否有【合規性的要求】：
- 如信用卡、金融卡，需要符合 PCI DSS 的標準，保護信用卡使用者的安全與保密需求。
- 金融單位合規，如《金融機構辦理電腦系統資訊安全評估辦法》
-
教育部委外辦理或補助建置維運伺服主機及應用系統網站資通安全及個人資料保護管理要點
- 病患資料
- 歐盟的個資法
- 台灣的個資法
設計需求
這個階段不外乎會繪製 UML 以及使用者等設計圖
也會透過透過威脅建模、風險評估，來設計安全架構。
- 資料保護：確保所有敏感資料（如密碼、信用卡號碼等）在儲存和傳輸時都進行適當的加密。
- 認證和授權：確保只有已認證的使用者可以存取他們應該存取的資料或功能。
- 安全的預設設定：避免使用預設的帳號/密碼，確保系統預設設定是最安全的。
- 錯誤處理：確保在出現錯誤時，不向使用者顯示敏感或技術資訊。（也就是 debug 要記得關)
- 安全內容確認：定期進行設計和程式碼審查以確保安全。
威脅建模
- 哪些類型的攻擊可能對我們的系統造成危害？例如，網路攻擊、惡意軟體、內部威脅等。
- 哪些資產可能會被攻擊者盜取、損壞或破壞？例如，敏感客戶資料、財務資訊、知識產權等。
- 哪些漏洞可能被攻擊者利用來入侵系統？例如，弱密碼、未更新的軟體、網站注入漏洞等。
- 攻擊者可能會利用哪些方法來進入系統？例如，社交工程、網路釣魚、漏洞掃描等。
- 攻擊者可能會使用哪些工具或技術來發動攻擊？例如，網路滲透測試工具、惡意程式碼等。
- 攻擊者的能力和資源如何？例如，是否是有企業的犯罪團伙、國家支持的駭客、單一駭客等。
- 攻擊者的意圖是什麼？例如，竊取資訊、勒索贖金、破壞系統等。
- 什麼是最高風險的攻擊場景？例如，攻擊者成功取得了系統管理權限、大規模的數據洩露等。
撰寫程式碼階段
- 撰寫程式碼的過程
- 根據需求撰寫安全功能
- 紀錄所有第三方套件的版本
- 不任意使用來路不明的工具
- 使用 ChatGPT 也要小心敏感資料外洩
- 常見的輸入輸出內容也需要注意
- 每一個模組都需要進行測試
測試階段
- 漏洞掃描(弱點掃描)
- 滲透測試：模擬真實的攻擊場景來評估系統的安全性。
- 靜態應用程式安全測試 (SAST)：分析原始碼以找出潛在的安全問題。
- 動態應用程式安全測試 (DAST)：在執行時分析應用程式以發現漏洞。
上線階段
- 部署過程要注意測試伺服器與正式伺服器
- 確保正式伺服器的環境設定和測試伺服器一致，如：OS 版本、套件和依賴版本等。
- 設定自動化部署工具，例如 Jenkins、GitLab CI/CD、或 GitHub Actions 等，確保每次部署都是可重覆的。
- 使用容器化工具，如 Docker，確保整體執行環境的一致性。
- 測試資料庫與正式資料庫
- 不要在正式資料庫上做測試。
- 定期備份正式資料庫，並確認可以正確回復。
- 使用資料庫遷移工具來管理資料庫結構的變更。
- 如果需要在正式資料庫上做任何行為，建議先在測試資料庫上模擬。
- .git 相關安全
- 確保 .gitignore 文件設定與權限，防止敏感資料、設定檔案或私有金鑰等被 push 到版本控制 git 當中。
- 定期檢查 git 日誌以找出是否不小心提交了敏感資訊。
- 若不小心提交了敏感資訊，可使用工具清理。
- 限制 git repository 的存取權限，確保只有授權的人員能存取。
- 監控上線
-
log 監控：
- 使用 log 管理工具如 ELK Stack (Elasticsearch, Logstash, Kibana) 或 Graylog 來集中管理、搜尋和分析日誌。
- 設定 alert 通知，當系統出現錯誤或異常時可以即時通知相關人員。
-
性能監控：
- 使用性能監控工具，如 New Relic、Datadog 或 Prometheus，來及時監測伺服器和應用程式的性能。
- 設定性能基礎內容，以便於比較和檢測異常。
- 定期檢查監控資料，找出性能瓶頸並進行優化。
iThome鐵人賽
看影片追技術